As network functionality increases, it is becoming increasingly more important for systems to allow applications and application components to be distributed across networks (e.g., on multiple application servers). For applications and application components to be effectively distributed, various distributed parts of applications and application components (i.e. nodes) need to be able to communicate with each other. As used herein, a node may be a software component or process that runs on a common computer or different computers connected by a network or networks. Furthermore, a node may be a message producer and/or a consumer. Consequently, nodes may communicate with each other using messaging to exchange information. The information may be sent and received by nodes using only a predetermined message format and a destination address for the message. The predetermined message format may include a message header for message identification, a properties section for application-specific, provider-specific, optional header fields—e.g., a “replyTo” header field to indicate the origin of the message for call back messages—and a body section that contains the content of the message. Moreover, the content of a message may include text, data packets, objects, or other information to be communicated between nodes.
As used in the context below, a “message” is a unit of information transmitted electronically from one computer application to another. Examples of messages generally include email messages and messages in data communications protocols such as HTTP or TCP/IP. Many messages in embodiments according to the present invention are units of information communicated in message oriented middleware (hereinafter referred to as “MOM”) framework (or system of software components and conventions that provide a message-oriented middleware architecture and features; see generally Chappell, “Enterprise Message Bus”, O'Reilly (2004)). MOM messages differ somewhat from many other kinds of messages. Email messages, for example, implement human-readable communications from a person to a person or from a software application to a person. HTTP messages represent requests for particular computer resources and responses to such requests. MOM messages, however, are used for communications between software applications and other software applications to implement business logic. That is, a MOM message generally communicates input data for, or output data from, operation of some form of business logic, accounting, on-line sales or marketing, financial calculations, security services, and so on. Examples of MOM systems include IBM's WebSphere MQ products and the Java Message Service (hereinafter referred to as “JMS”) Application Programming Interface (or “API”).
Several different types of messaging systems may be used for communicating between nodes including point-to-point and publish-and-subscribe. As seen in FIG. 1a, in a point-to-point messaging system (generally, a one-to-one delivery system), a message 105 may be sent by a message producer 101 to a message consumer 103 through a message queue 110 (also known as a virtual channel). For example, a message producer 101 may send a message 105 to a message queue 110 for a message consumer 103. The message consumer 103 receives and processes the message 105 from the message queue 110.
As seen in FIG. 1b, in a publish-and-subscribe messaging system (generally a one-to-many broadcast), the message producer 101 may be a publisher for a topic 123 (also known as a virtual channel) that sends a message 115 to several message consumers (known as subscribers) that have subscribed to the topic 123. For example, the message producer 101 may send a message 115 to a topic 123. Several nodes, such as the message consumer 103 and the second message consumer 121 may subscribe (i.e., request that messages of a certain type be sent to the node when available) to the topic 123. The topic 123 may deliver the message 115 to the message consumer 103 and the second message consumer 121. Message consumers not subscribed to the topic do not receive the message.
To facilitate sending and receiving messages, nodes typically connect to a messaging agent for implementing message queues and/or topics. One example of a messaging agent may be implemented according to the JMS API. Messages may be sent and received asynchronously, and nodes sending and receiving messages do not typically need to know anything about the nodes they are communicating with. This allows more freedom between nodes and makes it easier to design interfaces between nodes and easier to distribute applications and application components across a network.
In addition, some network environments may utilize clustered systems. A clustered system may include nodes participating in a messaging system. Alternatively, a cluster may include multiple nodes that behave as a single node in the messaging system. For example, a node may be an application component and may use JMS to access MOM systems for messaging with other nodes in a network to form a distributed system. MOM systems support distributed data communications that are loosely coupled and generally asynchronous. A producer component sends a message to a destination (typically a message queue), and a consumer recipient can retrieve the message from the destination. The producer and the consumer are not required to be available, either on-line or connected to one another for data communications in order to communicate. In fact, the producer does not need to know anything about the consumer, nor does the consumer need to know anything about the producer. The producer and consumer need to know only what message format and what destination (or message queue) to use. In this respect, messaging differs from tightly coupled technologies, such as the Common Object Request Broker Architecture (“CORBA”) or Java's Remote Method Invocation (“RMI”), which require a calling application to know a remote application's methods.
Consequently, a cluster of nodes may need to appear as a single producer/consumer for typical messaging systems. For example, confusion may result if two nodes in a cluster receive and process a topic message for which the cluster has subscribed to as a single entity. Also, it may be desirable for a cluster to support numerous different message-oriented middleware products.
In some environments, however, system operational requirements necessitate access to individual nodes (in a cluster or otherwise); for example, when a component expects a reply to a message that was sent. Consequently, within messaging in general, there is a messaging pattern such that a back-end application puts a message on a queue and sets a “replyTo” header that contains a specific Queue Manager (hereinafter referred to as “QM”) name. The intention being that the client takes the message, processes it and then sends a response back to the specified location.
Thus, it becomes desirable to uniquely identify a single producer/consumer within a messaging system. Exposing infrastructure externally, however, may violate security policies. For example, some MOM providers have developed HTTP bridges (e.g., IBM's Websphere MQ) to allow messages to pierce a corporate firewall. An HTTP bridge allows an HTTP client to connect to the “bridge” (often implemented as an HTTP servlet in the Java™ 2 Enterprise Edition Application Programming Interface, or simply J2EE API) and the bridge connects to the MOM provider (e.g., IBM's WebSphere MQ) on behalf of the HTTP client. In order to scale appropriately, however, HTTP relies on horizontal scaling; namely, by replicating the HTTP server within the operating environment and each HTTP server may be situated on a different machine (see generally, Joines et al. Performance analysis of Java Web Sites, pp. 102-106, Addison-Wesley (2002). In tandem with this replication, an HTTP client is usually mapped one-to-one with a HTTP servlet, within the HTTP server, and QM of the MOM provider. To enable better response times, each QM may be on its own machine.
Additionally, within such a horizontally scaled environment, system designers frequently avoid exposing machine details to the clients to avoid direct communication with specific HTTP servers, QM's and therefore machines. In particular, there are potential security ramifications about exposing a QM name such that the clients can trawl the known QM names for queues that are not exposed through the bridged applications naturally, and therefore gain illicit access to the underlying computing device. Within the above specified bridging & horizontally scaled environment this would mean exposing the QM name to the client. This leads to excessive client knowledge, which may violate the security policies of network and potentially allow illicit access to the underlying computing devices.